Systems and methods for warranty recommendation using multi-level collaborative filtering

ABSTRACT

Systems and methods are disclosed for warranty recommendations for users based upon warranty selections of peer users. The users are clustered into peer groups based upon industry or market segment based upon user data including primary variables, such as workload type data and market segment data, and secondary variables, such as virtual machine size or number, cluster size, cost, and downtime. New users are matched to a top similar user within their peer group based upon a vector distance, wherein the vector comprises the primary and secondary variables. A current warranty of the top similar user is recommended to the new user. Warranty changes by members of a peer group cause trigger an updated ranking of the peer group warranties. Expert user comments and rankings are used to generate expert user recommendations. A cost-based impact assessment may also be used for warranty recommendations by highlighting favorable and unfavorable warranty properties.

CROSS REFERENCE TO RELATED APPLICATIONS

This patent application claims priority to co-pending, commonly assignedIndian Patent Application No. 202111033261, filed Jul. 23, 2021 andentitled “Systems and Methods for Warranty Recommendation UsingMulti-Level Collaborative Filtering,” the entire contents of which areincorporated by reference herein.

FIELD

The present disclosure generally relates to Information Handling Systems(IHSs), and, more particularly, to recommending an optical IHS warrantyto users based on the user's community or market segment.

BACKGROUND

As the value and use of information continues to increase, individualsand businesses seek additional ways to process and store information.One option available to users is Information Handling Systems (IHSs). AnIHS generally processes, compiles, stores, and/or communicatesinformation or data for business, personal, or other purposes therebyallowing users to take advantage of the value of the information.Because technology and information handling needs and requirements varybetween different users or applications, IHSs may also vary regardingwhat information is handled, how the information is handled, how muchinformation is processed, stored, or communicated, and how quickly andefficiently the information may be processed, stored, or communicated.The variations in IHSs allow for IHSs to be general or configured for aspecific user or specific use such as financial transaction processing,airline reservations, enterprise data storage, or global communications.In addition, IHSs may include a variety of hardware and softwarecomponents that may be configured to process, store, and communicateinformation and may include one or more computer systems, data storagesystems, and networking systems.

Groups of IHSs may be housed within data center environments. A datacenter may include a large number of IHSs, such as enterprise bladeservers that are stacked and installed within racks. A data center mayinclude large numbers of such server racks that are organized into rowsof racks. Administration of such large groups of IHSs may require teamsof remote and local administrators working in shifts in order to supportaround-the-clock availability of the data center operations whileminimizing any downtime. A data center may include a wide variety ofhardware systems and software applications that may each be separatelycovered by warranties. The information available regarding warrantiescan be confusing for customers to understand the support level availablefor various IHSs in a data center.

SUMMARY

In various embodiments, systems and methods are provided for selectingwarranty recommendations for users based upon warranty selections ofpeer users, expert user advice, and cost-based impact assessment. Theusers are clustered into peer groups based upon industry or marketsegment. Peer groups are identified based upon user data includingprimary variables, such as workload type data and market segment data,and secondary variables, such as virtual machine size, a number ofvirtual machines, cluster size, cost, and a level of downtime. New usersare matched to an existing peer group. The new users are then matched toa top similar user within their peer group based upon a vector distance,wherein the vector comprise the primary and secondary variables. Acurrent warranty of the top similar user is recommended to the new user.Warranty changes by members of a peer group cause trigger an updatedranking of the peer group warranties. All members are notified of theupdated ranking.

Expert user comments and rankings are collected from experienced usersand existing customers. Warranties may also be ranked on the basis ofexpert user advice. Recognized experts in a selected industry or marketsegment may provide star ratings for warranties. These experts may alsoprovide review comments in conjunction with the star rating. The expertuser comments and rankings are used to generate expert userrecommendations.

A cost-based impact assessment may also be used for warrantyrecommendations. Cost recommendations highlight warranty properties thatare favorable and properties that may be impacted if the user makes atransition from one warranty to another. Different features associatedwith a warranty may be ranked as preferred, neutral, or not preferredwithin a particular industry or market segment. For example, featuressuch as SLA, downtime, expert rankings, or peer group rankings may bepresented to a customer for multiple warranties so that the customer canidentify the advantages and disadvantages in each warranty from a costpoint of view.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention(s) is/are illustrated by way of example and is/arenot limited by the accompanying figures. Elements in the figures areillustrated for simplicity and clarity and have not necessarily beendrawn to scale.

FIG. 1 is a block diagram illustrating certain components of a chassissupporting a plurality of IHSs and configured according to variousembodiments.

FIG. 2 is a block diagram illustrating certain components of an IHS thatmay be a component of a chassis and is configured according to variousembodiments.

FIG. 3 is a chart illustrating relative ratings of different warrantiesW1-W3 against attributes including downtime, SLA, peer group, and expertadvice.

FIG. 4 is a flowchart illustrating a process for data preprocessing andrecommendation according to an example embodiment.

DETAILED DESCRIPTION

Existing warranty systems typically comprise a standard warranty for aparticular device, such as an IHS, server, etc. The standard warrantycomprises typical coverage that is offered to customers by a vendor,such as a manufacturer, seller, re-seller, or subcontracted serviceagent, upon purchase of the individual device, such as a typical server,memory device, or network device warranty. In some cases, the vendor mayoffer an extended warranty if that option is available. The vendor maysupport many types of warranties, which can make it difficult for acustomer representative to select the correct warranty type applicablefor the customer product. For a larger customer accounts, the vendor mayallocate a dedicated Technical Account Manager (TAM), who can analyzethe customer requirements and help the customers with required warrantytypes. Unfortunately, customers may experience extended system downtimeor degraded functionality when a non-optimal warranty has been purchasedfor the device. There are multiple reasons that contribute to theselection of a non-optimal warranty, such as limited understanding ofcost or available warranty offerings, or changes in device usage orintent after purchase.

Warranties typically have common features, such as warranty type thatidentifies the covered component types (e.g., software or hardware), awarranty replacement SLA that identifies the level of services expectedby the customer from the vendor (e.g., next business day (NBD), secondbusiness day (SBD), four hours (4H), eight hours (8H), mission critical(MC), etc.), and a support type that identifies the types of supportprovided (e.g., engineer/technician level one, two, or three (L1, L1+L2,L1+L2+L3), Post Support, etc.) or other support based on standard namingconventions. The warranty will also identify a warranty start date and awarranty end date. The warranty SLA can have a significant impact on thecustomer's operations. For example, a server with an SBD warranty mayexperience downtime up to two days, which could have been reduced tofour hours if a 4H response warranty was in place.

Certain scenarios can create negative customer experiences if the wrongwarranty is in place. For example, a server's performance may bedegraded for an extended time due to redundant part failures, such asfailure of one drive in a Redundant Array of Independent Disks (RAID)virtual disk. A server may experience extended downtime due to the timerequired to replace a failed critical part, such as a CPU, memory,backplane, or system board failure. A servers may have to function withan extended risk due to redundant part failures, such as a power supplyunit (PSU) or fan failure. Customer awareness of warranty coverage mayalso cause customer dissatisfaction. For example, if a customer is notaware that a certain failure is within warranty support, then thecustomer will never report the issue and may instead request partreplacement, which may result in unnecessary downtime and cost thatcould have been avoided.

Existing warranty systems for data center devices, such as node,servers, clusters, etc. use standard collaborative filtering that isfocused on a single recommendation for a new user. After recommending awarranty to a new user, the existing methods do not recommend updatesfor that user even if the recommendations change later. There are toolsavailable that suggest a best warranty among available warranties for aspecific workload; however, those tools do not consider or makerecommendations based on the customer's peer group. When recommendingwarranties to a new user, existing systems do not consider the impactimportant properties such as SLA or server downtime. Additionally,existing warranty systems do not provide expert user recommendations.

FIG. 1 is a block diagram illustrating certain components of a chassis100 comprising one or more compute sleds 101 a-n and one or more storagesleds 102 a-n that may be configured to implement the systems andmethods described herein. As described in additional detail below, eachof the sleds 101 a-n, 102 a-n may be separately licensed hardwarecomponents and each of the sleds may also operate using a variety oflicensed hardware and software features. Chassis 100 may include one ormore bays that each receive an individual sled (that may be additionallyor alternatively referred to as a tray, blade, and/or node), such ascompute sleds 101 a-n and storage sleds 102 a-n. Chassis 100 may supporta variety of different numbers (e.g., 4, 8, 16, 32), sizes (e.g.,single-width, double-width), and physical configurations of bays. Otherembodiments may include additional types of sleds that provide varioustypes of storage and/or processing capabilities. Other types of sledsmay provide power management and networking functions. Sleds may beindividually installed and removed from the chassis 100, thus allowingthe computing and storage capabilities of a chassis to be reconfiguredby swapping the sleds with different types of sleds, in many caseswithout affecting the operations of the other sleds installed in thechassis 100.

By configuring a chassis 100 with different sleds, the chassis may beadapted to support specific types of operations, thus providing acomputing solution that is directed toward a specific type ofcomputational task. For instance, a chassis 100 that is configured tosupport artificial intelligence computing solutions may includeadditional compute sleds, compute sleds that include additionalprocessors, and/or compute sleds that include specialized artificialintelligence processors or other specialized artificial intelligencecomponents, such as specialized FPGAs. In another example, a chassis 100configured to support specific data mining operations may includenetwork controllers 103 that support high-speed couplings with othersimilarly configured chassis, thus supporting high-throughput,parallel-processing computing solutions.

In another example, a chassis 100 configured to support certain databaseoperations may be configured with specific types of storage sleds 102a-n that provide increased storage space or that utilize adaptationsthat support optimized performance for specific types of databases. Inother scenarios, a chassis 100 may be configured to support specificenterprise applications, such as by utilizing compute sleds 101 a-n andstorage sleds 102 a-n that include additional memory resources thatsupport simultaneous use of enterprise applications by multiple remoteusers. In another example, a chassis 100 may include compute sleds 101a-n and storage sleds 102 a-n that support secure and isolated executionspaces for specific types of virtualized environments. In someinstances, specific combinations of sleds may comprise a computingsolution, such as an artificial intelligence system, that may belicensed and supported as a computing solution.

Multiple chassis 100 may be housed within a rack. Data centers mayutilize large numbers of racks, with various different types of chassisinstalled in the various rack configurations. The modular architectureprovided by the sleds, chassis, and rack allow for certain resources,such as cooling, power, and network bandwidth, to be shared by thecompute sleds 101 a-n and the storage sleds 102 a-n, thus providingefficiency improvements, and supporting greater computational loads.

Chassis 100 may be installed within a rack structure that provides allor part of the cooling utilized by chassis 100. For airflow cooling, arack may include one or more banks of cooling fans that may be operatedto ventilate heated air away from a chassis 100 that is housed within arack. Chassis 100 may alternatively or additionally include one or morecooling fans 104 that may be similarly operated to ventilate heated airfrom within the sleds 101 a-n, 102 a-n installed within the chassis. Arack and a chassis 100 installed within the rack may utilize variousconfigurations and combinations of cooling fans 104 to cool the sleds101 a-n, 102 a-n and other components housed within chassis 100.

Sleds 101 a-n, 102 a-n may be individually coupled to chassis 100 viaconnectors. The connectors may correspond to bays provided in thechassis 100 and may physically and electrically couple an individualsled 101 a-n, 102 a-n to a backplane 105. Chassis backplane 105 may be aprinted circuit board that includes electrical traces and connectorsthat are configured to route signals between the various components ofchassis 100. In various embodiments, backplane 105 may include variousadditional components, such as cables, wires, midplanes, backplanes,connectors, expansion slots, and multiplexers. In certain embodiments,backplane 105 may be a motherboard that includes various electroniccomponents installed thereon. In some embodiments, components installedon a motherboard-type backplane 105 may include components thatimplement all or part of the functions described with regard tocomponents such as network controller 103, SAS (Serial Attached SCSI)adapter/expander 106, I/O controllers 107, and power supply unit 108.

In certain embodiments, a compute sled 101 a-n may be an IHS, such asdescribed with regard to IHS 200 of FIG. 2 . A compute sled 101 a-n mayprovide computational processing resources that may be used to support avariety of e-commerce, multimedia, business, and scientific computingapplications. In some cases, these applications may be provided asservices via a cloud implementation. Compute sleds 101 a-n are typicallyconfigured with hardware and software that provide leading-edgecomputational capabilities. Accordingly, services provided using suchcomputing capabilities are typically provided as high-availabilitysystems that operate with minimum downtime. Compute sleds 101 a-n may beconfigured for general-purpose computing or may be optimized forspecific computing tasks in support of specific computing solutions. Acompute sled 101 a-n may be a licensed component of a data center andmay also operate using various licensed hardware and software systems.

As illustrated, each compute sled 101 a-n includes a remote accesscontroller (RAC) 109 a-n. As described in additional detail with regardto FIG. 2 , a remote access controller 109 a-n provides capabilities forremote monitoring and management of each compute sled 101 a-n. Insupport of these monitoring and management functions, remote accesscontrollers 109 a-n may utilize both in-band and sideband (i.e.,out-of-band) communications with various internal components of acompute sled 101 a-n and with other components of chassis 100. Remoteaccess controller 109 a-n may collect sensor data, such as temperaturesensor readings, from components of the chassis 100 in support ofairflow cooling of the chassis 100 and the sleds 101 a-n, 102 a-n. Alsoas described in additional detail with regard to FIG. 2 , remote accesscontrollers 109 a-n may support communications with chassis managementcontroller 110 where these communications may report on the status ofhardware and software systems on a particular sled 101 a-n, 102 a-n,such as information regarding warranty coverage for a particularhardware and/or software system.

A compute sled 101 a-n may include one or more processors 111 a-n thatsupport specialized computing operations, such as high-speed computing,artificial intelligence processing, database operations, parallelprocessing, graphics operations, streaming multimedia, and/or isolatedexecution spaces for virtualized environments. Using such specializedprocessor capabilities of a compute sled 101 a-n, a chassis 100 may beadapted for a particular computing solution.

In some embodiments, each compute sled 101 a-n may include a storagecontroller that may be utilized to access storage drives that areaccessible via chassis 100. Some of the individual storage controllersmay provide support for RAID (Redundant Array of Independent Disks)configurations of logical and physical storage drives, such as storagedrives provided by storage sleds 102 a-n. In some embodiments, some orall of the individual storage controllers utilized by compute sleds 101a-n may be HBAs (Host Bus Adapters) that provide more limitedcapabilities in accessing physical storage drives provided via storagesleds 102 a-n and/or via SAS expander 106.

As illustrated, chassis 100 also includes one or more storage sleds 102a-n that are coupled to the backplane 105 and installed within one ormore bays of chassis 100 in a similar manner to compute sleds 101 a-n.Each of the individual storage sleds 102 a-n may include variousdifferent numbers and types of storage devices. For instance, storagesleds 102 a-n may include SAS (Serial Attached SCSI) magnetic diskdrives, SATA (Serial Advanced Technology Attachment) magnetic diskdrives, solid-state drives (SSDs), and other types of storage drives invarious combinations. The storage sleds 102 a-n may be utilized invarious storage configurations by the compute sleds 101 a-n that arecoupled to chassis 100. As illustrated, each storage sled 102 a-n mayinclude a remote access controller (RAC) 113 a-n. Remote accesscontrollers 113 a-n may provide capabilities for remote monitoring andmanagement of storage sleds 102 a-n in a similar manner to the remoteaccess controllers 109 a-n in compute sleds 101 a-n.

In addition to the data storage capabilities provided by storage sleds102 a-n, chassis 100 may provide access to other storage resources 115that may be installed as components of chassis 100 and/or may beinstalled elsewhere within a rack housing the chassis 100, such aswithin a storage blade. In certain scenarios, storage resources 115 maybe accessed via SAS expander 106 that is coupled to backplane 105 ofchassis 100. For example, SAS expander 106 may support connections to anumber of JBOD (Just a Bunch Of Disks) storage drives 115 that may beconfigured and managed individually and without implementing dataredundancy across the various drives 115. The additional storageresources 115 may also be at various other locations within the datacenter in which chassis 100 is installed. Such additional storageresources 115 may also be remotely located from chassis 100.

As illustrated, the chassis 100 of FIG. 1 includes a network controller103 that provides network access to the sleds 101 a-n, 102 a-n installedwithin the chassis. Network controller 103 may include various switches,adapters, controllers, and couplings used to connect chassis 100 to anetwork, either directly or via additional networking components andconnections provided via a rack in which chassis 100 is installed. Insome embodiments, network controllers 103 may be replaceable componentsthat include capabilities that support certain computing solutions, suchas network controllers 103 that interface directly with networkcontrollers from other chassis in support of clustered processingcapabilities that utilize resources from multiple chassis.

Chassis 100 may also include a power supply unit 108 that provides thecomponents of the chassis with various levels of DC power from an ACpower source or from power delivered via a power system provided by therack within which chassis 100 is installed. In certain embodiments,power supply unit 108 may be implemented within a sled that may providechassis 100 with redundant, hot-swappable power supply units. In suchembodiments, power supply unit 108 is a replaceable component that maybe used in support of certain computing solutions.

Chassis 100 may also include various I/O controllers 107 that maysupport various I/O ports, such as USB ports that may be used to supportkeyboard and mouse inputs and/or video display capabilities. I/Ocontrollers 107 may be utilized by a chassis management controller 110to support various KVM (Keyboard, Video and Mouse) 116 capabilities thatprovide administrators with the ability to interface with the chassis100.

In addition to providing support for KVM 116 capabilities foradministering chassis 100, chassis management controller 110 may supportvarious additional functions for sharing the infrastructure resources ofchassis 100. In some scenarios, chassis management controller 110 mayimplement tools for managing the network bandwidth 103, power 108, andairflow cooling 104 that are available via the chassis 100. Asdescribed, the airflow cooling 104 utilized by chassis 100 may includean airflow cooling system that is provided by a rack in which thechassis 100 may be installed and managed by a cooling module 117 of thechassis management controller 110.

As described, components of chassis 100 such as compute sleds 101 a-nand storage sleds 102 a-n may include remote access controllers 109 a-n,113 a-n that may collect information regarding the warranties forhardware and software systems on each sled. Chassis managementcontroller 110 may similarly collect and report information regardingthe warranties for hardware and software systems on each sled.

For purposes of this disclosure, an IHS may include any instrumentalityor aggregate of instrumentalities operable to compute, calculate,determine, classify, process, transmit, receive, retrieve, originate,switch, store, display, communicate, manifest, detect, record,reproduce, handle, or utilize any form of information, intelligence, ordata for business, scientific, control, or other purposes. For example,an IHS may be a personal computer (e.g., desktop or laptop), tabletcomputer, mobile device (e.g., Personal Digital Assistant (PDA) or smartphone), server (e.g., blade server or rack server), a network storagedevice, or any other suitable device and may vary in size, shape,performance, functionality, and price. An IHS may include Random AccessMemory (RAM), one or more processing resources such as a CentralProcessing Unit (CPU) or hardware or software control logic, Read-OnlyMemory (ROM), and/or other types of nonvolatile memory. Additionalcomponents of an IHS may include one or more disk drives, one or morenetwork ports for communicating with external devices as well as variousI/O devices, such as a keyboard, a mouse, touchscreen, and/or a videodisplay. As described, an IHS may also include one or more busesoperable to transmit communications between the various hardwarecomponents. An example of an IHS is described in more detail withrespect to FIG. 2 .

IHSs 107 a-d may be used to support a variety of e-commerce, multimedia,business, and scientific computing applications. In some cases, theseapplications may be provided as services via a cloud implementation.IHSs 107 a-d are typically configured with hardware and software thatprovide leading-edge computational capabilities. IHSs 107 a-d may alsosupport various numbers and types of storage devices. Accordingly,services provided using such computing capabilities are typicallyprovided as high-availability systems that operate with minimumdowntime. The warranties provided by vendors of IHSs 107 a-d and therelated hardware and software allow the data centers 101 a-d to providecontracted Service Level Agreement (SLA) to customers. Upon failure ofan IHS 107 a-d, data centers 101 a-d and operations center 102 typicallyrelies on a vendor to provide warranty support in order to maintaincontracted SLAs.

FIG. 2 illustrates an example IHS 200 configured to implement thesystems and methods described herein. It should be appreciated thatalthough the embodiments described herein may describe an IHS that is acompute sled or similar computing component that may be deployed withinthe bays of a chassis, other embodiments may be utilized with othertypes of IHSs. In the illustrative embodiment of FIG. 2 , IHS 200 may bea computing component, such as compute sled 101 a-n, that is configuredto share infrastructure resources provided by a chassis 100 in supportof specific computing solutions.

IHS 200 may be a compute sled that is installed within a large system ofsimilarly configured IHSs that may be housed within the same chassis,rack and/or data center. IHS 200 may utilize one or more processors 201.In some embodiments, processors 201 may include a main processor and aco-processor, each of which may include a plurality of processing coresthat, in certain scenarios, may each be used to run an instance of aserver process. In certain embodiments, one, some or all processor 201may be graphics processing units (GPUs). In some embodiments, one, someor all processor 201 may be specialized processors, such as artificialintelligence processors or processor adapted to support high-throughputparallel processing computations. As described, such specializedadaptations of IHS 200 may be used to implement specific computingsolutions support by the chassis in which IHS 200 is installed.

As illustrated, processor 201 includes an integrated memory controller202 that may be implemented directly within the circuitry of theprocessor 201, or memory controller 202 may be a separate integratedcircuit that is located on the same die as the processor 201. Memorycontroller 202 may be configured to manage the transfer of data to andfrom a system memory 203 of the IHS 201 via a high-speed memoryinterface 204.

System memory 203 is coupled to processor 201 via a memory bus 204 thatprovides the processor 201 with high-speed memory used in the executionof computer program instructions by the processor 201. Accordingly,system memory 203 may include memory components, such as such as staticRAM (SRAM), dynamic RAM (DRAM), or NAND Flash memory, suitable forsupporting high-speed memory operations by the processor 201. In certainembodiments, system memory 203 may combine both persistent, non-volatilememory, and volatile memory.

In certain embodiments, system memory 203 may be comprised of multipleremovable memory modules. System memory 203 in the illustratedembodiment includes removable memory modules 205 a-n. Each of theremovable memory modules 205 a-n may correspond to a printed circuitboard memory socket that receives a removable memory module 205 a-n,such as a DIMM (Dual In-line Memory Module), that can be coupled to thesocket and then decoupled from the socket as needed, such as to upgradememory capabilities or to replace faulty components. Other embodimentsof IHS system memory 203 may be configured with memory socket interfacesthat correspond to different types of removable memory module formfactors, such as a Dual In-line Package (DIP) memory, a Single In-linePin Package (SIPP) memory, a Single In-line Memory Module (SIMM), and/ora Ball Grid Array (BGA) memory.

IHS 200 may utilize a chipset that may be implemented by integratedcircuits that are connected to each processor 201. All or portions ofthe chipset may be implemented directly within the integrated circuitryof an individual processor 201. The chipset may provide the processor201 with access to a variety of resources accessible via one or morebuses 206. Various embodiments may utilize any number of buses toprovide the illustrated pathways served by bus 206. In certainembodiments, bus 206 may include a PCIe (PCI Express) switch fabric thatis accessed via a PCIe root complex. IHS 200 may also include one ormore I/O ports 207, such as PCIe ports, that may be used to couple theIHS 200 directly to other IHSs, storage resources or other peripheralcomponents. In certain embodiments, the I/O ports 207 may providecouplings to the backplane of the chassis in which the IHS 200 isinstalled.

As illustrated, a variety of resources may be coupled to the processor201 of the IHS 200 via bus 206. For instance, processor 201 may becoupled to a network controller 208, such as provided by a NetworkInterface Controller (NIC) that is coupled to the IHS 200 and allows theIHS 200 to communicate via an external network, such as the Internet ora LAN. As illustrated, network controller 208 may report information toa remote access controller 209 via an out-of-band signaling pathway thatis independent of the operating system of the IHS 200.

Processor 201 may also be coupled to a power management unit 211 thatmay interface with power system unit 108 of chassis 100 in which an IHS200, such as a compute sled 101 a-n, may be installed. In certainembodiments, a graphics processor 212 may be comprised within one ormore video or graphics cards, or an embedded controller, installed ascomponents of IHS 200. In certain embodiments, graphics processor 212may be an integrated of the remote access controller 209 and may beutilized to support the display of diagnostic and administrativeinterfaces related to IHS 200 via display devices that are coupled,either directly or remotely, to remote access controller 209.

As illustrated, IHS 200 may include one or more FPGA (Field-ProgrammableGate Array) card(s) 213. Each of the FPGA cards 213 supported by IHS 200may include various processing and memory resources, in addition to anFPGA integrated circuit that may be reconfigured after deployment of IHS200 through programming functions supported by FPGA card 213. Eachindividual FGPA card 213 may be optimized to perform specific processingtasks, such as specific signal processing, security, data mining, andartificial intelligence functions, and/or to support specific hardwarecoupled to IHS 200. In certain embodiments, such specialized functionssupported by an FPGA card 213 may be utilized by IHS 200 in support ofcertain computing solutions. As illustrated, FPGA 213 may reportinformation to the remote access controller 209 via an out-of-bandsignaling pathway that is independent of the operating system of the IHS200.

IHS 200 may also support one or more storage controllers 214 that may beutilized to provide access to virtual storage configurations. Forinstance, storage controller 214 may provide support for RAID (RedundantArray of Independent Disks) configurations of storage devices 215 a-n,such as storage drives provided by storage sleds 102 a-n and/or JBOD 115of FIG. 1 . In some embodiments, storage controller 214 may be an HBA(Host Bus Adapter). Storage controller 214 may report information to theremote access controller 209 via an out-of-band signaling pathway thatis independent of the operating system of the IHS 200.

In certain embodiments, IHS 200 may operate using a BIOS (BasicInput/Output System) that may be stored in a non-volatile memoryaccessible by the processor(s) 201. The BIOS may provide an abstractionlayer by which the operating system of the IHS 200 interfaces with thehardware components of the IHS. Upon powering or restarting IHS 200,processor 201 may utilize BIOS instructions to initialize and testhardware components coupled to the IHS, including both componentspermanently installed as components of the motherboard of IHS 200, andremovable components installed within various expansion slots supportedby the IHS 200. The BIOS instructions may also load an operating systemfor use by the IHS 200. In certain embodiments, IHS 200 may utilizeUnified Extensible Firmware Interface (UEFI) in addition to or insteadof a BIOS. In certain embodiments, the functions provided by a BIOS maybe implemented, in full or in part, by the remote access controller 209.

In certain embodiments, remote access controller 209 may operate from adifferent power plane from the processors 201 and other components ofIHS 200, thus allowing the remote access controller 209 to operate, andmanagement tasks to proceed, while the processing cores of IHS 200 arepowered off. As described, various functions provided by the BIOS,including launching the operating system of the IHS 200, may beimplemented by the remote access controller 209. In some embodiments,the remote access controller 209 may perform various functions to verifythe integrity of the IHS 200 and its hardware components prior toinitialization of the IHS 200 (i.e., in a bare-metal state).

Remote access controller 209 may include a service processor 216, orspecialized microcontroller, that operates management software thatsupports remote monitoring and administration of IHS 200. Remote accesscontroller 209 may be installed on the motherboard of IHS 200 or may becoupled to IHS 200 via an expansion slot provided by the motherboard. Insupport of remote monitoring functions, network adapter 208 c maysupport connections with remote access controller 209 using wired and/orwireless network connections via a variety of network technologies.

In some embodiments, remote access controller 209 may support monitoringand administration of various devices 208, 213, 214 of an IHS via asideband interface. In such embodiments, the messages in support of themonitoring and management function may be implemented using MCTP(Management Component Transport Protocol) that may be transmitted usingI2C sideband bus connections 217 a-c established with each of therespective managed devices 208, 213, 214. As illustrated, the managedhardware components of the IHS 200, such as FPGA cards 213, networkcontroller 208 and storage controller 214, are coupled to the IHSprocessor 201 via an in-line bus 206, such as a PCIe root complex, thatis separate from the I2C sideband bus connection 217 a-c.

In certain embodiments, the service processor 216 of remote accesscontroller 209 may rely on an I2C co-processor 218 to implement sidebandI2C communications between the remote access controller 209 and managedcomponents 208, 213, 214 of the IHS. The I2C co-processor 218 may be aspecialized co-processor or micro-controller that is configured tointerface via a sideband I2C bus interface with the managed hardwarecomponents 208, 213, 214 of IHS. In some embodiments, the I2Cco-processor 218 may be an integrated component of the service processor216, such as a peripheral system-on-chip feature that may be provided bythe service processor 216. Each I2C bus 217 a-c is illustrated as singleline in FIG. 2 . However, each I2C bus 217 a-c may be comprised of aclock line and data line that couple the remote access controller 209 toI2C endpoints 208 a, 213 a, 214 a.

As illustrated, the I2C co-processor 218 may interface with theindividual managed devices 208 , 213, and 214 via individual sidebandI2C buses 217 a-c selected through the operation of an I2C multiplexer219. Via switching operations by the I2C multiplexer 219, a sideband busconnection 217 a-c may be established by a direct coupling between theI2C co-processor 218 and an individual managed device 208, 213, or 214.

In providing sideband management capabilities, the I2C co-processor 218may each interoperate with corresponding endpoint I2C controllers 208 a,213 a, 214 a that implement the I2C communications of the respectivemanaged devices 208, 213, 214. The endpoint I2C controllers 208 a, 213a, 214 a may be implemented as a dedicated microcontroller forcommunicating sideband I2C messages with the remote access controller209, or endpoint I2C controllers 208 a, 213 a, 214 a may be integratedSoC functions of a processor of the respective managed device endpoints208, 213, 214.

In various embodiments, an IHS 200 does not include each of thecomponents shown in FIG. 2 . In various embodiments, an IHS 200 mayinclude various additional components in addition to those that areshown in FIG. 2 . Furthermore, some components that are represented asseparate components in FIG. 2 may in certain embodiments instead beintegrated with other components. For example, in certain embodiments,all or a portion of the functionality provided by the illustratedcomponents may instead be provided by components integrated into the oneor more processor 201 as a systems-on-a-chip.

In some embodiments, the remote access controller 209 may include or maybe part of a baseboard management controller (BMC). As a non-limitingexample of a remote access controller 209, the integrated Dell RemoteAccess Controller (iDRAC) from Dell® is embedded within Dell PowerEdge™servers and provides functionality that helps information technology(IT) administrators deploy, update, monitor, and maintain serversremotely. In other embodiments, chassis management controller 110 mayinclude or may be an integral part of a baseboard management controller.Remote access controller 209 may be used to monitor, and in some casesmanage computer hardware components of IHS 200. Remote access controller209 may be programmed using a firmware stack that configures remoteaccess controller 209 for performing out-of-band (e.g., external to acomputer's operating system or BIOS) hardware management tasks. Remoteaccess controller 209 may run a host operating system (OS) 221 on whichvarious agents execute. The agents may include, for example, a servicemodule 250 that is suitable to interface with remote access controller209 including, but not limited to, an iDRAC service module (iSM).

IHSs vendors offer diverse warranty types with various SLAs and support.Typically, customers choose a warranty for the IHSs they buy based ontheir needs and based on their knowledge and experience. Warrantyrequirements differ based on the market segment (e.g., automotive, webtechnologies, finance, banking, etc.) as well as the workload needs(customer relationship management (CRM), business management,mail/calendaring server, real-time data processing, LAMP stack, etc.).Each workload has a different priority across different industries basedon how they influence the business.

Currently, customers do not have collective market intelligence toassist in making warranty decisions. Initially customers tend to go withthe vendor's recommendations. Later, based on experience, customers mayend or modify some warranty options. Finally, when the customer has todeal with hard issues such as server failure events, they startconfiguring the correct warranty options. Some of the reasons that makewarranty selection difficult for customers include:

-   -   New customers who are not aware of the vendor's warranty models;    -   Vendors who enter a new market segment with customers that have        a unique or different workload compared to an existing customer        base;    -   New evolutions in technology as well as market segment needs        that require new warranty expectations;    -   New SLA definitions based on recent experiences in the market        segment (e.g., GDP, privacy laws, and additional disaster        recovery needs); and    -   Warranty needs that vary with workloads in a market segment due        to specific behaviors in that segment. For example, the finance        and banking industries require faster and definitive SLAs,        whereas the automotive and web technology industries usually        create their own frameworks for handling hardware/software        downtime and, therefore, have different warranty needs.

In an example embodiment, workloads for a virtual storage area network(VSAN) or software-defined storage (SDS) in a banking or finance segmentmay not use the same warranty as a web technologies warranty. While anNBD (Next Business Day) or SBD (Second Business Day) warranty may beacceptable for the web technologies industry, critical warranties suchas 4-hour or 8-hour SLAs are required in the banking and financeindustry due to the impact of downtime on the business. Similarly, webtechnology companies may require less part-replacement warranties, whilecompanies in the automotive industry rely on software technologies,which requires less part replacement.

In one embodiment, a multi-level, collaborative-filtering based warrantyrecommendation is used to identify the desired level of warranty for newor existing users based upon the community or market segment to whichthat user belongs. This solution may be deployed using cloud-basedproactive monitoring and predictive analytics, such as CloudIQ from DellInc., where the computation for a warranty recommendation may beexecuted.

The solution is categorized into at least two categories: presalerecommendations and customer recommendations. A presale collaborativefiltering-recommendation is made at the time of purchase using, forexample, a vendor sales tool. The vendor's sales team recommends thebest warranty based on feedback and data from similar companies in thesame industry segment. A customer collaborative filtering recommendationcan be made in a systems management tools, such as the Dell EMCOpenManage Enterprise (OME) or Dell EMC SupportAssist Enterprise (SAE).The recommendations are made available through these tools based on thechanges in the usage pattern of the other users in the same marketsegment. Customers can use the customer-collaborative recommendation toupgrade warranties based on other users' experience.

Users receive customized warranty recommendations that are marketsegment specific based on multiple factors such as SLA, level ofdowntime, usage in peer groups, or expert advice. The collaborativefiltering is extended in multiple stages. In one embodiment, a proposedmulti-level collaborative filtering-based warranty recommendationconsists of the following stages:

Stage 1: Peer group discovery and preliminary warranty recommendation.

In this state, significant properties, such as workload type and marketsegment, are combined with other properties, such as virtual machine(VM) sizing and cost, from various datacenters and deployments. Theseproperties are collected and processed to find related user groups.

Stage 2: Detect changes in warranty sets within peer group.

Changes in peer group behavior are monitored. Changes from a previouswarranty recommendation to a current warranty recommendation based onchanges in the behavior of a peer group over the course of time arebroadcast and propagated to users within that peer group. After asuggested warranty level is recommended to a new user or an upgradingexisting user, it may happen that other users in the same peer groupmove from one warranty set to another warranty set. These changes in thewarranty sets are identified, and then the changes are suggested tousers to be consistent. Warranties are ranked to be recommend incorrespondence with similar users based on the market segment andworkloads. In this stage, a new warranty for a peer group is determinedusing the technique explained described in Stage 1, and then the newrecommendation is provided to the peer group to ensure consistency.

Stage 3: Compute and propagate warranty ranks.

In this stage, warranty ranks are computed and then changes arebroadcast and propagated within peer groups. The changes in warrantyranking may be used by customers to switch to more popular warranties.Peer group classification is based on workloads and market segment.There may be multiple warranties W 1 , W 2 , . . . , Wn that arerecommended based on similar users. These warranties may be ranked basedon usage in the peer group. Ranking of warranties may be accomplished bycreating a hash table with the key as a unique warranty identifier and avalue equal to the number of users using that particular warranty. Thehash table is sorted in decreasing order of the values, and the rankinglist of warranties is generated. The warranty rankings may also bepublished as part of a user or peer group change in Stage 2.

Stage 4: Expert user recommendation.

Particular users can be tagged as expert users based on factors such asstar ratings and sentimental analysis of review comments. In the peergroups for those particular users, their recommendations can beconsidered as expert user recommendations. Warranties may be ranked onthe basis of expert user advice. Recognized experts in an industry orsegment may provide comments or other feedback, and any user may providea star rating for the warranties. The expert review comments can beconsidered in conjunction with the star ratings in order to generate anexpert user recommendation.

Expert users may be ranked themselves, such as type A, B, or C users.The expert users may submit their recommendations to a vendor cloud. Thecustomers may provide ratings for workload type and the warranties usedin their system These recommendations will be tagged with the primaryvariables (e.g., workload type and market segment) for which the user isconsidered as an expert. Type A Expert Users are special types of userswho submit proposals regarding warranty sets based on their knowledge.Type B Expert Users are based on ratings from customers and arecorrelated to a specific market segment. Type C Expert Users arecustomers who give review comments along with a star rating. Reviewcomments express the true notion of sentiments behind a particularwarranty. Vendors may prefer to use review comments for ranking of aparticular warranty only if there are more than half of the customersgiving review comments; otherwise, star ratings are preferred. Whenconsidering review comments, the vendor performs a sentiment analysis ofthe comments after preprocessing of the data. A polarity greater than0.5 would be classified as positive, polarity in range [−0.5, 0.5] wouldbe neutral, and polarity lesser than −0.5 would be classified asnegative. Warranties may be ranked with a decreasing order of polarity.When considering star rating, an average of the ratings for each of thewarranties is calculated, and a ranked list of the warranties isprepared on the basis of the average star rating.

Stage 5: Cost impact in recommendation.

Many users will be concerned about the cost of the warranties suggestedin the above stages. In this step, the impact on different IT attributes(e.g., SLA, downtime, etc.) or peer group/expert behavior is computedbased on the warranty cost. FIG. 3 is a chart 300 illustrating an impactassessment for different warranties W1-W3. Impact assessment showsrelative ratings against attributes including downtime, SLA, peer group,and expert advice for each warranty. Cost recommendations are concernedwith the properties that might get impacted when the user makes atransition from one warranty to another. As depicted, if a customermoves from warranty W1 to warranty W2, then the SLA will get impactedwhereas there will be less downtime for W2. Higher ranked warranties inthe peer group are depicted as the most preferred warranties whereaslower ranked warranties are depicted as not-preferred warranties withsuitable impact assessment for other attributes like SLA and downtime.

The warranty recommendations may be computed within a cloud-basedproactive monitoring and predictive analytics tool and then propagatedto users via a system management tool. New warranty suggestions may bepropagated to all users in a peer group, for example, using alerts in aserver management tool.

The use of separate sets of attributes (primary variables) and secondaryvariables for computation of peer groups is not used in existingwarranty systems. The primary variables are the workload type and themarket segment, which are used to construct peer groups. Existingwarranty systems also lack the ability for continuous computation ofchanges in warranty sets based on customer usage patterns. Moreover,existing warranty systems do not provide automated computation ofwarranty ranks based on usage pattern in the peer groups. Finally,existing systems do not incorporate expert user recommendations into thewarranty recommendation process.

One or more of the functions involved in warranty rankings, such as datasourcing, identifying peers, detecting changes in warranties, computingwarranty ranks, collecting expert user advice, and evaluating costconcerns, may be automated and performed in an artificial intelligence(AI) or machine learning (ML) engine or processor that executes softwareinstructions that operate to combine large amounts of data with fast,iterative processing and intelligent algorithms, which thereby allow thesoftware to automatically learn from patterns and features in the data.The AI/ML device may be hosed on an IHS and may use machine learning,which automates analytical model building using methods from neuralnetworks and statistics to find insights into data without explicitlyprogramming regarding what to look for and what to conclude. The AI/MLdevice may use a neural network that is made up of interconnected unitsthat process information by responding to external inputs and relayinginformation between each unit. The process may require multipleiterations processing the data to find connections and derive meaningfrom unstructured data. The AI/ML device may use advanced algorithms toanalyze large amounts of data faster and at multiple levels. This allowsintelligent processing for identifying and predicting rare events,understanding complex systems, and identifying unique scenarios. TheAI/ML device may use application programming interfaces (APIs) to addfunctionality to existing systems and software. The AI/ML device canreason on input data and output an explanation of the data.

AI/ML algorithms for ranking warranties are trained using an appropriateset of parameters. For example, the AI/ML device may be trained usingparameter related to workload type, market segment, VM sizing, number ofVMs, cluster size, cost, downtime, warranty SLAs and other terms andconditions. The algorithm generates recommendations for recommendingwarranties to customers based on market segment. The warranty data iscategorized by assigning weights and bias to each parameter andidentifying opportunities to group warranties and customers by industrygroups.

FIG. 4 is a flowchart illustrating a process 400 for data preprocessingand recommendation according to an example embodiment. In step 401,various data sources are identified. As part of data preparation,various distinct properties for a user in a particular market segmentare considered, such as primary variables (e.g., workload type, marketsegment) and secondary variables (e.g., number of VMs deployed for theworkload, VM sizing, cluster size, cost, and level of downtime). Peergroups are created based upon this data. In step 402, the data ispreprocessed. Some of the primary or secondary variables may containtextual data that will require text preprocessing. Text preprocessingincludes conversion of text data into lowercase and splitting the textinto words. Tokenization preprocessing may also be used to remove stopwords.

In step 403, one or more vectors are created. Vectorization is a form ofword embedding. Term Frequency-Inverse Document Frequency (TF-IDF) isutilized to create a vector representation for each user in a particularcommunity or market segment. In step 404, a vector is computed for newusers by TF-IDF with high importance being assigned to the primaryvariables noted above. Once market segment and new users' vectors arecreated, then similarities between users can be identified. To groupusers, an unsupervised clustering methodology based on a distancemeasurement algorithm is used.

In step 405, a cosine similarity is used as a distance algorithm forcomputing clusters. The cosine similarity is calculated between each newuser and the previously identified peer groups (i.e., community ormarket segment). Based on the cosine similarity, new peer-group clustersare discovered and/or new users are matched to a peer-group clusterbased upon the least distance between a user and a cluster.

In step 406, a determination is made whether the user is a new user. Ifthe user is new, then they may optionally be offered expert adviceregarding warranty options in step 407; otherwise, new users andexisting users seeking a warranty review/update move to step 408. Instep 408, a determination is made whether the recommendation is for asingle warranty by a top similar user. If so, the in step 409 a warrantyrecommendation is created by identifying the top similar user in thesame peer group and then recommending the warranty used by that topsimilar user. If more than one warranty is recommended, then in step 410a determination is made whether there is a significant differencebetween the prior users who have used the recommended group ofwarranties. If so, then in step 411, a warranty is recommended based onwhich prior user is closest to the current user.

If there is no significant difference among the users in step 410, thenin step 412 a comparison is made among the warranties' costs. If thereare significant cost differences, then in step 413 a decision is madewhether the customer has indicated that cost is a concern. If cost is aconcern, then in step 414 the least costly warranty is recommended tothe customer along with an impact assessment for that warranty withrespect to SLA, downtime, peer group, and expert advice similar to theexample shown in FIG. 3 . If cost is not a concern in step 413, or ifthere are not significant cost differences between the group ofwarranties, then in step 415 the group of warranties are recommended tothe customer with the highest ranked warranty identified as mostpreferred. The customer is also provided an impact assessment for groupof warranties with respect to SLA, downtime, peer group, and expertadvice for each warranty similar to the example shown in FIG. 3 . Thecustomer may then select from the among the offered warranties.

In an example embodiment, a method for filtering warranty offers basedon user peer groups comprises collecting data associated with aplurality of warranty users, wherein the data corresponds to a set ofprimary variables and a set of secondary variables; creating a vectorrepresentation of each user using TF-IDF; identifying two or moreclusters of warranty users, wherein each cluster is created using acosine similarity comparison of the user vector representations;identifying a top similar user for each cluster; determining a warrantytype for each top similar user; and notifying other users within eachcluster of the warranty type associated with the top similar user forthat cluster. Each of the two or more clusters of warranty users areassociated with a different market segment.

The method for filtering warranty offers may further comprise creating avector representation for a new user using TF-IDF, calculating a cosinesimilarity between the new user vector and a closest top similar user,and notifying the new user of the warranty type associated with theclosest top similar user.

The set of primary variables may comprise one or more of workload typedata and market segment data. The set of secondary variables maycomprise one or more of a virtual machine size, a number of virtualmachines, a cluster size, a cost, and a level of downtime.

Each cluster may correspond to a peer group, and the method forfiltering warranty offers may further comprise determining when a userwithin a peer group has changed to a warranty; identifying a new topsimilar user for the peer group; determining a warranty type for the newtop similar user; and notifying other users within the peer group of thewarranty type associated with the new top similar user.

The method for filtering warranty offers may further compriseidentifying each warranty used by members of a cluster; rank thewarranties for the cluster based upon a number of users for eachwarranty; and publishing a top warranty for the cluster to other membersof the cluster.

The method for filtering warranty offers may further comprise collectinga group of user rankings for warranties used within a cluster;collecting review comments regarding the warranties used within thecluster; and generating an expert user recommendation for one or more ofthe warranties used within the cluster. The expert user recommendationmay correspond to a highest average rating for the warranty.

The method for filtering warranty offers may further comprise, for aplurality of warranties, creating an indication for each warrantywhether the warranty is preferred or not preferred for one or more ofthe primary variables and secondary variables.

In another example embodiment, a computer program product comprises acomputer readable storage medium having program instructions embodiedtherewith. The program instructions are executable by a processor tocause the processor to perform a method comprising identifying, using amachine learning algorithm, a plurality of peer groups among a number ofwarranty users, wherein the peer groups correspond to market segments orindustries; identifying, using the machine learning algorithm, a topsimilar user within a selected peer group for a new user, wherein thetop similar user is selected based upon a cosine similarity of vectormodels representing the top similar user and the new user; and notifyingthe new user of a preferred warranty, wherein the preferred warrantycorresponds to a current warranty associated with the top similar user.

The program instructions may further cause the processor to identifywhen a user assigned to a peer group has changed to a new warranty;create a ranking of current warranties within the peer group thatincludes the new warranty; and notify users in the peer group of theranking of current warranties. Notifying users of the ranking of currentwarranties may comprise, for example, identifying a top warranty amongthe current warranties. The top warranty may correspond to a warrantythat is used most often by users with the peer group.

The ranking of current warranties may be based upon data correspondingto a set of primary variables and a set of secondary variables. The setof primary variables may comprise one or more of workload type data andmarket segment data, and the set of secondary variables may comprise oneor more of a virtual machine size, a number of virtual machines, acluster size, a cost, and a level of downtime. The program instructionsmay further cause the processor to determine whether each warranty ofthe current warranties is preferred or not preferred or neutral for oneor more of the set of primary variables and the set of secondaryvariables.

The program instructions may further cause the processor to collect userrankings of current warranties associated with users in a peer group;collect review comments regarding current warranties associated withusers in a peer group; and create a ranked list of the currentwarranties based upon average values of the user ranking and reviewcomments.

The program instructions may further cause the processor to create aranking of current warranties within the peer group, wherein the rankingis sorted based upon warranty cost.

It should be understood that various operations described herein may beimplemented in software executed by logic or processing circuitry,hardware, or a combination thereof. The order in which each operation ofa given method is performed may be changed, and various operations maybe added, reordered, combined, omitted, modified, etc. It is intendedthat the invention(s) described herein embrace all such modificationsand changes and, accordingly, the above description should be regardedin an illustrative rather than a restrictive sense.

Although the invention(s) is/are described herein with reference tospecific embodiments, various modifications and changes can be madewithout departing from the scope of the present invention(s), as setforth in the claims below. Accordingly, the specification and figuresare to be regarded in an illustrative rather than a restrictive sense,and all such modifications are intended to be included within the scopeof the present invention(s). Any benefits, advantages, or solutions toproblems that are described herein with regard to specific embodimentsare not intended to be construed as a critical, required, or essentialfeature or element of any or all the claims.

Unless stated otherwise, terms such as “first” and “second” are used toarbitrarily distinguish between the elements such terms describe. Thus,these terms are not necessarily intended to indicate temporal or otherprioritization of such elements. The terms “coupled” or “operablycoupled” are defined as connected, although not necessarily directly,and not necessarily mechanically. The terms “a” and “an” are defined asone or more unless stated otherwise. The terms “comprise” (and any formof comprise, such as “comprises” and “comprising”), “have” (and any formof have, such as “has” and “having”), “include” (and any form ofinclude, such as “includes” and “including”) and “contain” (and any formof contain, such as “contains” and “containing”) are open-ended linkingverbs. As a result, a system, device, or apparatus that “comprises,”“has,” “includes” or “contains” one or more elements possesses those oneor more elements but is not limited to possessing only those one or moreelements. Similarly, a method or process that “comprises,” “has,”“includes” or “contains” one or more operations possesses those one ormore operations but is not limited to possessing only those one or moreoperations.

What is claimed is:
 1. A method for filtering warranty offers based onuser peer groups, comprising: collecting data associated with aplurality of warranty users, wherein the data corresponds to a set ofprimary variables and a set of secondary variables; creating a vectorrepresentation of each user using Term Frequency-Inverse DocumentFrequency (TF-IDF); identifying two or more clusters of warranty users,wherein each cluster is created using a cosine similarity comparison ofthe user vector representations; identifying a top similar user for eachcluster; determining a warranty type for each top similar user; andnotifying other users within each cluster of the warranty typeassociated with the top similar user for that cluster.
 2. The method ofclaim 1, further comprising: creating a vector representation for a newuser using TF-IDF; calculating a cosine similarity between the new uservector and a closest top similar user; and notifying the new user of thewarranty type associated with the closest top similar user.
 3. Themethod of claim 1, wherein the set of primary variables comprises one ormore of workload type data and market segment data, and wherein the setof secondary variables comprises one or more of a virtual machine size,a number of virtual machines, a cluster size, a cost, and a level ofdowntime.
 4. The method of claim 1, wherein each of the two or moreclusters of warranty users are associated with a different marketsegment.
 5. The method of claim 1, wherein each cluster corresponds to apeer group, and the method further comprising: determining when a userwithin a peer group has changed to a warranty; identifying a new topsimilar user for the peer group; determining a warranty type for the newtop similar user; and notifying other users within the peer group of thewarranty type associated with the new top similar user.
 6. The method ofclaim 1, further comprising: identifying each warranty used by membersof a cluster; rank the warranties for the cluster based upon a number ofusers for each warranty; and publishing a top warranty for the clusterto other members of the cluster.
 7. The method of claim 1, furthercomprising: collecting a group of user rankings for warranties usedwithin a cluster; collecting review comments regarding the warrantiesused within the cluster; and generating an expert user recommendationfor one or more of the warranties used within the cluster.
 8. The methodof claim 7, wherein the expert user recommendation corresponds to ahighest average rating for the warranty.
 9. The method of claim 1,further comprising: for a plurality of warranties, creating anindication for each warranty whether the warranty is preferred or notpreferred for one or more of the primary variables and secondaryvariables.
 10. A computer program product comprising a computer readablestorage medium having program instructions embodied therewith, theprogram instructions executable by a processor to cause the processor toperform a method comprising: identifying, using a machine learningalgorithm, a plurality of peer groups among a number of warranty users,wherein the peer groups correspond to market segments or industries;identifying, using the machine learning algorithm, a top similar userwithin a selected peer group for a new user, wherein the top similaruser is selected based upon a cosine similarity of vector modelsrepresenting the top similar user and the new user; and notifying thenew user of a preferred warranty, wherein the preferred warrantycorresponds to a current warranty associated with the top similar user.11. The computer program product of claim 10, wherein the programinstructions further cause the processor to perform a method comprising:identifying when a user assigned to a peer group has changed to a newwarranty; creating a ranking of current warranties within the peer groupthat includes the new warranty; and notifying users in the peer group ofthe ranking of current warranties.
 12. The computer program product ofclaim 11, wherein notifying users of the ranking of current warrantiescomprises identifying a top warranty among the current warranties. 13.The computer program product of claim 12, wherein the top warrantycorresponds to a warranty that is used most often by users with the peergroup.
 14. The computer program product of claim 11, wherein the rankingof current warranties is based upon data corresponding to a set ofprimary variables and a set of secondary variables.
 15. The computerprogram product of claim 14, wherein the set of primary variablescomprises one or more of workload type data and market segment data, andwherein the set of secondary variables comprises one or more of avirtual machine size, a number of virtual machines, a cluster size, acost, and a level of downtime.
 16. The computer program product of claim14, wherein the program instructions further cause the processor toperform a method comprising: determining whether each warranty of thecurrent warranties is preferred or not preferred or neutral for one ormore of the set of primary variables and the set of secondary variables.17. The computer program product of claim 10, wherein the programinstructions further cause the processor to perform a method comprising:collecting user rankings of current warranties associated with users ina peer group; collecting review comments regarding current warrantiesassociated with users in a peer group; and creating a ranked list of thecurrent warranties based upon average values of the user ranking andreview comments.
 18. The computer program product of claim 11, whereinthe program instructions further cause the processor to perform a methodcomprising: creating a ranking of current warranties within the peergroup, wherein the ranking is sorted based upon warranty cost.